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(57) Abstract 

An account processing method and sys- 
tem for providing specific pre-authorization pa- 
rameters for transactions that require specific 
pre-authorization by a network user specify- 
ing conformity parameters within which any re- 
quested transaction parameters must comply in 
order to enable the requested transaction to be ap- 
proved. Upon establishment of an account, trans- 
action types by standard industrial code (SIC) are 
specified as needing specific authorization prior 
to approving the transaction as requested by a 
merchant. An account issuer provides a service 
to account members that permits network user to 
independently specify the parametric conditions 
under which to approve a transaction within such 
categories. Once a transaction is approved, the 
pre-authorization is spent and requires individ- 
ual pre-authorization of each transaction, thereby 
minimizing misuse of an account number by mer- 
chants or others that come into possession of the 
network user's account number. 
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B£JLAI£D APPLICATIONS 
This application is a continuation-in-part of U.S. Patent Application Serial 
No. 08/957,419 filed October 24, 1997 entitled "System and Method for Pre- 
Authorization of Individual Account Transactions." 

RACKflROUND OF THE INVENTION 

1. Tjie Field of the Invention 

The present invention relates to electronic authorization of financial 
transactions, and in particular, to electronic authorization of specific predetermined 
transactions. More particularly, the present invention relates to specific 
authorization of individual transactions otherwise inhibited or 
prohibited. 

2. present State of the Art 

Modernly, more and more transactions in commerce have come to rely upon 
the convenience of utilizing a transaction card such as a credit card for the 
purchasing of goods and services. As credit cards have become more ubiquitous, 
so also has the infrastructure supporting the use of credit cards in commerce. At 
one point, what was a simple relationship between a card issuer and a cardholder 
has evolved to include intermediaries providing authorization services and 
financial distribution services. Such an expansive infrastructure has come to 
facilitate on-line or near real-time transaction authorization. 

Furthermore, because of the extensive nature of the credit card 
infrastructure, additional users, not necessarily relying upon credit, also utilize the 
existing infrastructure in carrying out commerce. For example, businesses or 
corporations may establish a series of accounts with a card issuer and distribute 
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transaction cards to their members for use in executing cashless transactions. To 
minimize fraud and abuse in the purchasing of goods and services, authorization 
standards have been established. Figure 1 represents a standardized authorization 
process for transaction verification. An account manager, such as a fleet manager 
or other entity, desiring cashless transaction privileges contacts a card issuer 1 14 
to request the extension of transaction privileges through an established account 
request 116. Typically, when establishing a credit account, card issuer 1 14 places 
restrictions such as transaction amount limitations upon the card user. However 
when establishing accounts for business or other like users, account manager 102 
may request that card issuer 1 14 deny certain transactions and strictly enforce other 
limitations on transactions. 

Exemplary desired account limitations include restrictions on the types of 
services and goods that may be procured by an account user 104 as directed by 
account manager 102. Industry standards have been established for the partitioning 
of goods and services into categories designated by a standard industrial code 
(SIC). A merchant 106 is assigned a specific standard industrial code 
corresponding to their predominate business function. For business transactions 
that adhere to the SIC coding, transactions originating at a point of sale terminal 
having a restricted SIC identifier may be unable to obtain proper authorization to 
complete a transaction with an account user. Other limitations frequently desired 
by account managers include transactional limits. Transactional limits may include 
single transaction limits or aggregate limitations upon successive transactions. 

Card issuer 1 14 upon the establishment of an account may employ a third 
party authorizing agent to provide authorization services and strictly enforce 
transaction limitations as agreed upon between account manager 102 and card 
issuer 114. Card issuer 1 14 through an establish authorization request 118 informs 
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authorizing agent 112 of the transaction terms under which transaction 
authorization may be granted. 

Once an account has been established account manager 102 provides the 
account information necessary to enable account user 104 to engage in commerce 
transactions. Such account information generally includes an account number as 
assigned by card issuer 114. The predominate form of providing account 
information to account user 104 is to provide account user 104 with a transaction 
card generally taking the form of a credit card-like card bearing the account number 
thereon. Account user 104 upon initiating a transaction with a merchant 106 
engages in a payment presentment step 120 by providing the requisite account 
information to merchant 106. Merchant 106 engages in an authorization process 
to verify that the transaction parameters of the present transaction are within the 
boundaries or limitations placed upon the account as requested by account 
manager 102 or imposed by card issuer 1 14. An authorization request 122 issued 
by merchant 106 is comprised of an account number, a transaction amount and 
other parameters such as a standard industrial code (SIC), a merchant identifier 
(MID) and an acquiring bank identification number (BIN). 

A merchant 106 typically associates with an acquiring bank 108 which 
provides funding services of merchant transactions. Authorization requests may 
electronically pass through acquiring bank 108 as designated by the BIN of the 
authorization request and additionally may route through a card company 110 (e.g., 
MasterCard®, VISA®, Discover Card® or American Express®) prior to reaching 
authorizing agent 112 for comparison of account parameters. Authorizing 
agent 112 compares the transaction parameters for conformance with account 
limitations. Authorizing agent 112 issues an authorization response 124 
comprising an acceptance or denial indicator. 



I 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 



00/57374 



5 



PCT/US00/07975 



During general authorization processing, funds generally do not transfer at 
that time. A settlement generally occurs at a periodic time such as evenings or 
nights when a merchant re-initiates communication with an authorizing agent and 
presents a series of accepted and authorized transactions occurring throughout the 
previous period and requests financial settlement of such transactions. 
Merchant 106 initiates a settlement request 126 with authorizing agent 1 12 which 
generally comprises the account number to be debited, the amount of the debit and 
other information such as SIC, MID and BIN designators. As part of the settlement 
process, authorizing agent 112 issues a settlement request 128 to card issuer 114. 
Frequently a settlement request 128 includes less cryptic merchant information 
(i.e., merchant name and city /state address instead of MID) for later presentment 
to an account manager. Card issuer 1 14 in a payment settlement response step 130 
passes payment information on to merchant's acquiring bank 108 with the 
appropriate funds transferring in a step 131. 

At yet another periodic point in time, card issuer 114 provides a billing 
account 132 to account manager 102 for notification of payment due or for other 
record keeping purposes. Such billing account information may be presented in 
various forms including printed statements as well as electronic reporting. In such 
generic authorization processing as described above, billing account information 
contains relatively little and non-descriptive information such as an account 
number, a transaction amount and merchant information. 

At least three particular shortcomings of the authorization process as 
described in Figure 1 should be pointed out. First, authorization performed by 
authorizing agent 112 provides a regulation of transactions by either proscribing 
transactions originating at a merchant having a proscribed SIC goods/services 
designator, or withholding authorization from transactions that exceed 
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transactional limits. Such an authorization process approves transactions of values 
less than the transactional limits transpiring at non-proscribed merchant point of 
sale terminals having a non-barred SIC goods/services designator. Prior art 
authorization techniques do not provide a method or system for enforcing strict 
transaction parameters prior to authorization of restricted transaction types on a 
transaction by transaction basis. Additionally, prior art techniques do not permit 
an account manager to create transaction authorization parameters without re- 
initiating account establishment procedures. 

A second shortcoming of the authorization processing in the prior art 
relates to billing account information sent from card issuer 1 14 for evaluation by 
account manger 102. As shown in Figure 1, the billing account information is 
comprised of an account number and an amount coupled to merchant information 
such as the name and city of the merchant. An account manager does not have a 
tracking mechanism to track the execution of a specific transaction and the billing 
of such a transaction on a billing statement if the vendor and acquiring bank cannot 
provide this functionality. In prior art configurations, the account manager only 
discerns that a certain amount of money, a transaction amount, was exchanged with 
a specific merchant. 

Other transaction systems have incorporated item descriptions generally 
ascertainable from SKU numbers listing goods or services obtained from the listed 
merchant into their billing statements. It should be noted that such techniques still 
do not provide a tracking mechanism for linking a specific authorization procedure 
to a billing account printout. 

A third short coming of the authorization processing in the prior art relates 
to the inability to prevent fraudulent successive transactions using the account 
number of an account user once it has been divulged to a merchant. In many 
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instances and applications, transactions are performed remotely from the physical 
presence of the account user thereby foreclosing the account user from 
discretionary evaluation of the credibility of the merchant with which an account 
user's account number would be divulged. In such an application, the rogue 
merchant would be free to utilize the account number in successive authorization 
requests and alternatively could resell or post an account user's account number for 
indiscriminate use by other devious entities. Because such an opportunity exists 
such as in the case of remote network and chiefly Internet purchasing 
environments, account users have theretofore been hesitant to engage in electronic 
commerce using a credit or other form of transaction card or vehicle that exposes 
an account user's account number into an environment whose security is at best 
suspect. 

Accordingly, what is needed is a method and system for authorizing in 
advance or pre-authorizing transactions that but for specific authorization, are 
otherwise proscribed. 

What is also needed is a method and system for enforcing parameters upon 
such pre-authorized transactions such as transaction amounts, specific merchants 
and other transaction related parameters. 

Also, what is yet needed, is a method and system for facilitating an audit 
or record reconciliation from a pre-authorized transaction through the billing of the 
account thus informing an account manager of the completion of a pre-authorized 
transaction. 
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SUMMARY AND OBJECTS OF THE INVENTION 

It is an object of the present invention to provide a method for authorizing 
an account when a portion of the account transactions require individual pre- 
authorization according to specified pre-authorization parameters. 

It is another object of the present invention to provide a system for 
authorizing an account when a portion of the account transactions require 
individual pre-authorization according to specified pre-authorization parameters. 

It is a further object of the present invention to provide a method for 
authorizing a portion of account transactions otherwise denied by requiring 
individual pre-authorization according to parameters pre-authorized in a pre- 
authorization process. 

It is yet another object of the present invention to provide a method and 
system for associating a transaction identifier within a pre-authorization process 
such that upon the completion of the transaction, the associated transaction 
identifier follows the transaction information through the billing account phase, 
thus allowing reconciliation of a specific transaction from a previously assigned 
transaction identifier. 

It is still yet another object of the present invention to provide a method and 
system for authorizing all account transactions which without such pre- 
authorization would otherwise be denied in wholesale. Such a method and system 
enforces a collateral pre-authorization of each and every transaction in order to 
approve or accept an authorization transaction initiated by a merchant entity. 

Additional objects and advantages of the invention will be set forth in the 
description which follows, and in part will be obvious from the description, or may 
be learned by the practice of the invention. The objects and advantages of the 
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invention may b'e realized and obtained by means of the instruments and 
combinations particularly pointed out in the appended claims. 

To achieve the foregoing objects, and in accordance with the invention as 
embodied and broadly described herein, an account processing method and system 
for facilitating the general denial of all or specific categories of transactions unless 
they are specifically pre-authorized with specified parameters and the parameters 
of the requested transaction conform to those pre-authorized parameters is 
provided. Additionally, the present invention provides a system and method for the 
pre-authorization of specific transactions to be performed by an account manager 
via a service provided by an account issuer to their customers such as account 
managers and users. 

A further advancement of the present invention provides a method and 
system for allowing an account manager to define a transaction identifier (e.g., 
insurance claim number, purchase order number, work order number, etc.) and 
attach the transaction identifier through a pre-authorization of a transaction. Upon 
the initiation and authorization of a requested transaction conforming to the 
specified pre-authorization parameters, the transaction identifier is included with 
the generic billing information (e.g., transaction amount, merchant information, 
etc.) thus allowing an account manager to reconcile their accounting from a billing 
account information containing the transaction having the transaction identifier 
associated thereto with a pre-transaction assignment of a traditional identifier such 
as purchase order number, work order number, or insurance claim number. 

The above described system and method includes an account establishment 
phase of an account process wherein an account manager approaches a card 
issuer to establish an account in an establish account step. During the 
establishment of an account, limitations on transactions relating to that account are 
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negotiated between the account manager and card issuer. Transaction limitations 
generally include items such as transaction limits, account balance limit, 
limitations on categories of goods or services as denoted by standard industrial 
codes (SIC) and other parameters that may be incorporated into a specific 
accounting scheme. In an alternate embodiment, a system and method is described 
wherein a consumer-to-business transaction environment, the account user 
personally initiates the account establishment phase with the card issuer. 

In the present invention, upon the establishment of an account or during the 
amending or changing of an account, transactions involving certain categories of 
goods or services as denoted by pre-authorization SICs that denote categories of 
goods or services, have individual parametric constraints placed upon them- A card 
issuer employs the services of an authorizing agent for performing account 
authorization upon the initiation of a transaction request from a merchant. The 
card issuer, in an establish authorization step, forwards various parameters such as 
SIC limits that wholly bar categories of transactions, transaction limits relating to 
non-pre-authorization transactions and pre-authorization SICs designating 
categories of goods or services requiring specific authorization in conformance 
with pre-authorization parameters subsequently dispatched to the designated 
authorizing agent in a pre-authorization process. 

In the present invention, once an account is established with a card issuer, 
an account manager may perform pre-authorization of transactions with the card 
issuer directly. In the preferred embodiment, an account manager using a 
communication device such as a personal computer may routinely generate pre- 
authorization requests by transferring pre-authorization parameters to the card 
issuer via communication channel such as the INTERNET. In an alternate 
embodiment such as a consumer-to-business environment, the account user may 
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personally perform the transaction pre-authorization directly with the card issuer. 
In a remote or networking-type environment, the account user may pre-authorize 
the transaction by employing a network such as the INTERNET which enables the 
account user to interface with the card issuer through a card issuer's interactive 

interface such a web page. 

A typical scenario wherein the present invention is practiced provides for 
a pre-authorization transaction phase that commences with a request by an account 
user for a specified good or service that requires pre-authorization prior to 
initiating the transaction. The account user consults with the account manager for 
requesting restricted goods or services. The account manager in turn contacts the 
merchant for negotiating or obtaining a price quotation for the requested goods or 
services, or optionally; the account manager arrives at a quotation amount by 
consulting other traditional pricing sources such as directories or catalogs. 

The account manager issues a pre-authorization request to the card issuer 
via a personal computer. The account manager in the pre-authorization 
request specifies an account number for which pre-authorization transaction 
parameters apply. In the preferred embodiment, one or more transaction 
parameters including a quote amount resulting from the quotation process, an 
acceptable variance or deviation range from the quotation amount, a merchant 
identifier (MID) or an acquiring bank identification number (BIN) are dispatched 
to the card issuer. It should be pointed out that in the present invention, one or 
more of the pre-authorization parameters may be specified while others may not be 
specified thus permitting the spectrum of possible options for such criteria. The 
card issuer relays the pre-authorization parameters to the authorizing agent for 
storage and usage during authorization processing. In an alternate consumer-to- 
merchant environment, the account user assumes the role of the account manager 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
II 
12 
13 
14 
13 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 



00/57374 



12 



PCI7US00/07975 



by both seeking out the goods or services to be procured and additionally by pre- 
authorizing or approving a future transaction that undergoes a merchant 
authorization request. 

Another aspect of the present invention includes the ability to input or 
provide a transaction identifier for association with an authorized completed 
transaction. The transaction identifier, in the preferred embodiment, provides an 
alpha-numeric field wherein an identifier may be specified and associated with a 
pre-authorized transaction and upon the initiation and authorization of the 
requested transaction, the transaction identifier is reported in the billing account 
information. Such a transaction identifier enables an account manager to associate 
a pre-authorization of a transaction with a transaction reported in a billing account 
thereby allowing reconciliation of accounting entries. 

The pre-authorization parameter record remains within the authorizing 
agent until a matching transaction is initiated by an account user. When an account 
user initiates a transaction for goods or services, a merchant initiates an 
authorization request for approval. In the present invention, the authorization 
request takes the form of presentment of a transaction card or other credit card-like 
credentials bearing an account number as previously assigned for use by the 
account user. An account user or account manager may present the account number 
to the merchant using means other than a transaction card such as the presentment, 
verbal disclosure, electronic disclosure or written disclosure of an account number 
to the merchant. 

During the authorization, the merchant forwards the account number, the 
transaction amount, and alternatively other information such as the merchant's SIC 
denoting its category of goods or services, the merchant's MID and the acquiring 
BIN associated wUh the merchant. The authorizing agent performs the 
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authorization process which includes consulting the pre-authorization table when 
the merchant SIC presented in the authorization request corresponds to a pre- 
authorization SIC presented during the establishment of the account. The 
authorizing agent issues an authorization response listing the acceptance or denial 
status resulting from the authorization process. 

During the settlement of the account, generally at the end of the business 
day, the merchant forwards the account numbers, the transaction amounts and other 
pertinent and related information such as the merchant's SIC and city location 
relating to each of the authorized transactions for the day. In one embodiment of 
the present invention, the authorizing agent additionally forwards the transaction 
identifier as received in the pre-authorization request. In the billing account issued 
by the account issuer to the account manager, the billing account includes details 
of the account number, the transaction amount, merchant information and when 
present the transaction identifier. By presenting the transaction identifier to the 
account manager, transactions authorized in the pre-authorize transaction phase 
may be traced through the authorization, settlement and reporting phases of account 
processing. By tracing or having a designator assigned to a specific transaction, 
the accounting resources of the account manager may close out such transactions 
upon reporting the completion of the transaction. 

In a networked consumer user-to-merchant environment, such as in an 
electronic commerce environment, the individual pre-authorization of each 
transaction by a user prior to the actual payment presentment activity, minimizes 
the fraudulent use of an account user's account number when divulged during a 
payment presentment step. Such misuse is curbed due to the fact that any 
subsequent authorization requests by a merchant or unauthorized user would be 
denied since the account user would not have individually pre-authorized each and 
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every transaction attempted by the user rogue merchant thereby denying subsequent 
debits against the account user's account. 

These and other objects and features of the present invention will become 
more fully apparent from the following description and appended claims, or may 
be learned by the practice of the invention as set forth hereinafter. 
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RR1FF INSCR IPTION OF THE DRAWINGS 

In order that the manner in which the above-recited and other advantages 
and objects of the invention are obtained, a more particular description of the 
invention briefly described above will be rendered by reference to specific 
embodiments thereof which are illustrated in the appended drawings. 
Understanding that these drawings depict only typical embodiments of the 
invention and are not therefore to be considered limiting of its scope, the invention 
will be described and explained with additional specificity and detail through the 
use of the accompanying drawings in which: 

Figure 1 is a flow diagram of an authorization process, in accordance with 

the prior art; 

Figure 2 is a flow diagram of a pre-authorization process, in accordance 
with a preferred embodiment of the present invention; 

Figure 3 is a block diagram of an authorization table including both 
standard and pre-authorization tables as stored within an authorizing agent, in 
accordance with a preferred embodiment of the present invention; 

Figure 4 is a flow chart of a transaction authorization procedure in a pre- 
authorization-capable authorizing agent, in accordance with an embodiment of the 
present invention; 

Figure 5 is a representative billing statement containing a transaction 
identifier as associated with a pre-authorized transaction and subsequently 
forwarded to an account manager upon completion of a pre-authorized transaction, 
in accordance with an embodiment of the present invention; 

Figure 6 is a flow diagram illustrating account processing which employs 
pre-authorization of select transactions without requiring an account user to 
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perform a payment presentation step, in accordance with an embodiment of the 
present invention; 

Figure 7 is a simplified transaction diagram for use in a wide-area 
networking environment, in accordance with a preferred network embodiment of 
the present invention; 

Figure 8 is a flow diagram of a pre-authorization process for use in a wide- 
area networking environment, in accordance with a preferred network embodiment 
of the present invention; and 

Figure 9 is a block diagram of an authorization table including both 
standard and pre-authorization tables as stored within an authorizing agent, in 
accordance with a preferred network embodiment of the present invention. 
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nr.T AILED DESCRIPTION Q£ THE PREFERRED EMBODIMENTS 

As used herein, the term "account manager" refers to an individual or 
organization charged with establishing and monitoring an account. An account 
manager may be in charge of many accounts and take the form of fleet managers, 
accounting managers, claims adjusters and also prudent account users. 

As used herein, the term "account user" refers to an individual, consumer 
or organization seeking goods or services and may also take the form of fleet users, 
business personnel and insured parties. It should be noted that an account manager 
and an account user may be the same party. 

As used herein, the term "merchant" refers to an individual or organization 
providing goods or services in exchange for a fee. Merchants generally facilitate 
the reimbursement transaction by providing a point-of-sale terminal or other device 
through which a transaction is initiated including a computer network interface for 
interacting over a network such as a LAN or WAN including the Internet. 

As used herein, the term "acquiring bank" refers to a financial institution 
providing financial services for an associated merchant. An acquiring bank is 
generally a bank or like organization at which a merchant maintains an account for 
reconciliation of funds. 

As used herein, the term "bank card association" refers to a sponsoring 
organization that provides financial services and brings organization and 
infrastructure into the account processing. 

As used herein, the term "authorizing agent" refers to an organization 
which may be part of a card company and provides assurances to a merchant of the 
good standing of the account in question and conformity of the requested 
transaction to limitations and parameters placed upon a transaction. 
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As used herein, the term "account or card issuer" refers to an organization 
providing administrative services to an account user or account manager. Account 
issuer may also provide augmented services to an account user or manager such as 
access to an authorizing agent for account establishment and other functions such 
as pre-authorization. 

As used herein, the term "authorization web page" refers to a computer 
network-accessible intermediary interface into which a web account user 
(consumer) may place parametric transaction authorization information that is 
forwarded to an authorizing agent for use in evaluating the legitimacy of a specific 
transaction. 

It should also be appreciated that the functions of the "bank card 
association," "authorizing agent," "card issuer," and the sponsor of an 
authorization web page" may be one or several entities providing a combination 
of these functions. 

As described in the Background of the Invention, Figure 1 is a flow diagram 
of an authorization process in accordance with the prior art. 

Figure 2 is a flow diagram of account processing incorporating pre- 
authorization of individual transactions or transaction types, in accordance with a 
preferred embodiment of the present invention. As account processing has become 
increasingly prevalent and sophisticated, the complexities of account processing 
have also increased. For example, in the establishment and processing of an 
account, additional specified participants are incorporated into the processing flow. 
In one preferred embodiment, during an account establishment phase of an account 
process, an account manager 202 approaches a card issuer 214 to establish an 
account as represented in Figure 2 by establish account step 216. During the 
establishment of an account, limitations on transactions relating to that account are 
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negotiated between account manager 202 and card issuer 214. Transaction 
limitations generally include items such as transaction limits, account balance 
limit, limitations on categories of goods or services as denoted by standard 
industrial codes (SIC) and other parameters that may be incorporated into a specific 
account scheme. 

In the present embodiment of the invention, upon the establishment of an 
account or during the amending or changing of an account, transactions involving 
certain categories of goods or services as denoted by pre-authorization SICs denote 
goods or services that require individual parametric constraints upon such 
transactions. For example, account manager 202 may establish an account for use 
by an account user 204 for performing maintenance upon a fleet vehicle. In order 
to police the use of the account for limited maintenance purposes, account 
manager 202 designates the SIC associated with maintenance as a pre-authorization 
SIC requiring conformity to transaction parameters subsequently defined by 

account manager 202. 

Card issuer 214 employs the services of an authorizing agent 212 for 
performing account authorization upon the initiation of a transaction request from 
a merchant. Card issuer 214 in establish authorization step 218 forwards SIC limits 
controlling categories of transactions, transaction limits relating to non-pre- 
authorization transactions and pre-authorization SICs designating categories of 
goods or services requiring specific authorization according to pre-authorization 
parameters subsequently dispatched to authorizing agent 212. 

In the present invention, once an account is established with a card issuer, 
account manager 202 may perform pre-authorization of transactions with card 
issuer 214 directly. In the preferred embodiment, account manager 202 using a 
personal computer may routinely generate pre-authorization requests by 



6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 



00/57374 



20 



PCT/US00/07975 



transferring pre-authorization parameters to card issuer 214 via the INTERNET, 
A pre-authorization transaction phase commences with a request 220 by an 
account user 204 for a specified good or service that requires pre-authorization 
prior to initiating the transaction. Account user 204 consults with account 
manager 202 to obtain restricted goods or services. Account manager 202 in turn 
contacts a merchant 206 for negotiating or obtaining a price quotation 222, 
including a quote amount for the requested goods or services. Optionally, account 
manager 202 may consult a price quotation directory or catalog containing price 
quotations for goods or services as requested by account user 204. In yet another 
option, account manager 202 may independently generate or approximate a quote 
amount for a requested goods or service for use in the pre-authorization process. 

Account manager 202 issues a pre-authorization request 224 to card 
issuer 214, in the preferred embodiment, using a personal computer that is 
electronically coupled to card issuer 214. Account manager 202 in pre- 
authorization request 224 specifies an account number for which pre-authorization 
transaction parameters apply. In the preferred embodiment, one or more 
transaction parameters including a quote amount resulting from the quotation 
process, an acceptable variance, or deviation range from the quotation amount, a 
merchant identifier (MID) and an acquiring bank identification number (BIN) are 
dispatched to card issuer 214. It should be pointed out that in the present 
invention, one or more of the pre-authorization parameters may be specified while 
others may not be specified, thus permitting the spectrum of possible options for 
such criteria. For example, account manager 202 may specify a quote amount and 
a variance or deviation from the quote amount, such as in the case permitting the 
inclusion of sales tax with the quoted transaction amount, while leaving the 
merchant identifier and acquiring bank identification number unspecified, thereby 
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permitting an account user to seek out the goods or services of any merchant for 
processing the requested transaction. 

Another field that may be input or provided by account manager 202 is a 
transaction identifier field. The transaction identifier, in the preferred 
embodiment, provides an alpha-numeric field wherein an identifier may be 
associated with a pre-authorized transaction and upon the initiation and 
authorization of the requested transaction, the transaction identifier is reported in 
the billing account information. Such a transaction identifier enables an account 
manager to associate a pre-authorization of a transaction with a transaction 
reported in a billing account thereby allowing reconciliation of accounting entries. 

Referring to Figure 2, card issuer 214 employs its established relationship 
with authorizing agent 212 to forward a pre-authorization request 226 comprised 
of the account number and other transaction parameters which may optionally 
include a transaction identifier. Authorizing agent 212 retains and stores the pre- 
authorization transaction parameters in a pre-authorization table 318 (Figure 3) for 
subsequent authorization when a transaction presents an SIC corresponding to one 
designated as a pre-authorization SIC. 

The pre-authorization parameter records remain within authorizing 
agent 212 until a matching transaction is initiated by an account user. Optionally, 
pre-authorization parameters may become stale and expire if not timely used. 
Account user 204 requests goods or services from merchant 206 and thereafter 
initiates a payment presentment 228 for reimbursement to merchant 206. In the 
preferred embodiment, payment presentment 228 takes the form of presentment of 
a transaction card or other credit card-like credentials bearing an account number 
as previously assigned for use by account user 204. It should be noted that the 
present invention does not require account user 204 to present tangible credentials 
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bearing an account number, but also accommodates the presentment of an account 
number to a merchant In intangible form, such as the recitation of an account 
number to merchant 206 for discrete key entry by merchant 206 at the 
commencement of the authorization process. 

In yet another embodiment as detailed in Figure 6, account manager 202 
(Figure 2) rather than account user 204 (Figure 2) divulges an account number for 
use by merchant 206 (Figure 2) upon the rendering of goods or services. Such a 
process has application to businesses such as the insurance industry wherein 
account manager 202 may play the role of a claims adjuster disclosing an account 
number to merchant 206 for payment of services rendered for an insurance claim. 

Returning to a discussion of the embodiment depicted in Figure 2, 
merchant 206 upon receipt of the account number information verifies the status 
and acceptance parameters of the present account by performing an authorization 
request 230 with authorizing agent 212. Merchant 206 forwards the account 
number, transaction amount, the merchant's SIC denoting its category of goods or 
services, the merchant's MID and the acquiring BIN associated with merchant 206. 
Authorizing agent 212 performs the authorization process which includes 
consulting the pre-authorization table when the merchant SIC presented in 
authorization request 230 corresponds to a pre-authorization SIC presented in 
establish authorization step 218. The authorization process of authorizing 
agent 212 is detailed in the flowchart of Figure 4. At the conclusion of the 
authorization process, authorizing agent 212 issues an authorization response 232 
listing the acceptance or denial status resulting from the authorization process to 
merchant 206. 

Generally at the authorization phase of a transaction, funds do not transfer 
between the parties. Rather, a settle account phase generally occurs at a periodic 
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point in time such as at the end of a business day or week. At such time, 
merchant 206 compiles a complete listing of authorized transactions occurring 
within the specified period which includes the present transaction of the previous 
discussion, and initiates a settlement request 234 with authorizing agent 212 by 
divulging the account number, the transaction amount and other pertinent and 
related information such as the merchant's SIC, MID and BIN. 

In some financial configurations, authorizing agent 212 may also act as an 
account clearinghouse providing account settlements for card issuers having an 
established relationship with authorizing agent 212. Authorizing agent 212 issues 
a settlement request 236 to card issuer 214 which may contain the same or similar 
information as received from settlement request 234 or as shown in settlement 
request 236 may contain more descriptive information such as a merchant name and 
city as opposed to an MID. In one embodiment of the present invention, 
authorizing agent 212 additionally forwards the transaction identifier as received 
in pre-authorization request 226. Card issuer 214 issues payment settlement 
response 238 to acquiring bank 208 with the subsequent settlement response 239 
for settlement of the account resulting from the present transaction. 

Card issuer 214 issues a billing account 240 to account manager 202 
detailing the account number, the transaction amount, merchant information and, 
when present, the transaction identifier. By presenting the transaction identifier 
to account manager 202 transactions authorized in the pre-authorize transaction 
phase may be traced through the authorization, settlement and reporting phases of 
account processing. By tracing or having a designator assigned to a specific 
transaction, the accounting resources of account manager 202 may close out such 
transactions upon the reporting of the completion of the transaction. 
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1 Figure 3 is a simplified diagram of authorization tables employed by an 

2 authorizing agent for use in comparison of parameters of a requested transaction 

3 with authorization limitations placed upon transaction, in accordance with an 

4 embodiment of the present invention. An authorization agent 212 (Figure 2) stores 

5 therein an authorization table 300 containing parameter limitations as previously 

6 designated during the establish account phase of an account processing procedure. 

7 During a traditional authorization procedure, the authorizing agent references a 

8 standard authorization table containing limitations such as an SIC limit 312, a 

9 transaction limit 3 14 and a balance limit 3 16. In the present invention specified 

10 categories of transactions may be allowed to proceed when a pre-authorization 
it process has taken place. Such transaction categories are stored within 

12 authorization table 300 in a pre-authorization SIC table 302. 

13 . As illustrated in Figure 3, SICs 304, 306 *nd 308 correspond to SIC 

14 category codes X, Y and Z, respectively, and designate transaction categories 
.5 requiring consultation with a pre-authorization table 318 to determine the 

16 authorization of a requested transaction. In the preferred embodiment, pre- 

17 authorization table 318 is comprised of a series of fields designating transaction 

18 parameters that must be in compliance prior to issuing an authorization of the 

19 requested transaction. Such transaction parameters include a quote amount 322, 

20 a variance 324, a merchant ID (MID) 326 and an acquiring bank identification 

21 number (BIN) 328. Quote amount 322 is comprised of an upper price boundary for 

22 an approved transaction. A variance parameter 324 optionally provides tolerance 

23 values for accommodating variations in "amounts." For example, a variance may 

24 typically take the form of sales tax or regionalized price fluctuations or other 

25 variations. Merchant identifier 326 optionally may provide a parameter requiring 

26 I the transaction to originate from a designated merchant or point of sale location. 
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Furthermore, acquiring bank identification number 328 may optionally provide a 
further grouping of select merchants and employ a specified bank before 
authorizing the transaction in question. 

In another embodiment, a transaction identifier 330 is associated with pre- 
authorization transaction parameters during the pre-authorization process. Such 
association of an identifier permits a pre-authorizing agent such as an account 
manager to specify a purchase order number, a work order number or an insurance 
claim number to be included within the pre-authorization parameters of such goods 
or such services. Following the initiation and authorization of a transaction 
wherein the pre-authorization parameters were matched, the transaction identifier 
is attached with the settlement request information, depicted as settlement 
request 236 (Figure 2), for conveying the transaction information to a card issuer 
for reconveyance to the account manager. Upon receipt of the transaction identifier 
associated , with the completed transaction account manager 202 may rectify 
accounting books or other records referencing the transaction identifier because the 
transaction identifier was associated with the billing account and request for 
payment. Such a technique enables a merchant to receive payment almost 
immediately upon the dispatch of a settlement request and relieves the 
accompanying correspondence associated with "cutting" a purchase order and 
writing a check for accounts payable. 

In an alternate embodiment of the present invention, pre-authorization 
table 318 further comprises an SIC identifier field 320 for associating with a 
specific set of pre-authorization parameters. Furthermore, each parameter within 
the pre-authorization table need not be specified allowing greater flexibility to an 
account user in selecting vendors of goods or services. 
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Figure 4 is a flowchart of an authorization process incorporating pre- 
authorization, in accordance with a preferred embodiment of the present invention. 
An authorizing agent pre-authorization verification process 402 is carried out 
within an authorizing agent such as authorizing agent 212 described in Figure 2. 
Although the previous discussions including Figure 2 have illustrated entities such 
as authorizing agents being separate from card issuers, nothing prevents the 
combination of these elements into a single entity carrying out both processes 
therein. For example an account manager 202 (Figure 2) and account user 204 
(Figure 2) may easily be combined into a single entity that both manages and uses 
an established account. Additionally, acquiring banks and card companies may 
further be included within other entities such as a card issuer or authorizing agent. 

Authorizing agent pre-authorization verification process 402, in the 
preferred embodiment, is carried out by an authorizing agent 212 (Figure 2) by 
consulting a ^re-authorization's SIC table 302 (Figure 3) of authorization table 300. 
A query task 404 compares the SIC value of the requested transaction with those 
previously stored within the pre-authorization SIC table 302 (Figure 3) during the 
establishment of the account phase. When the SIC code of the requested 
transaction does not match a SIC code specifically requiring additional pre- 
authorization, a standard authorization processing task 406 occurs wherein the 
standard authorization table 310 (Figure 3) having specific limitations such as 
transaction or balance limits is performed. 

When query task 404 determines that the SIC code of the requested 
transaction corresponds with a SIC code requiring pre-authorization, a query 
task 408 performs a cursory evaluation upon the pre-authorization table to 
determine if there is a pre-authorization entry present. When a pre-authorization 
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entry is not present, a deny transaction task 410 returns a deny transaction status 
in the authorization response 232 (Figure 2). 

When query task 408 locates pre-authorization data within the pre- 
authorization table, a query task 412 evaluates the requested transaction amount 
against the quote amount including any variance parameters included within the 
pre-authorization table. When the requested transaction amount exceeds the quote 
amount including any variances, the requested transaction is denied as described 
above. When the requested transaction amount does not exceed the boundaries 
established by the quote amount including any variances, a query task 414 further 
evaluates any other specified parameters such as merchant ID (MID) or acquiring 
bank identification number (BIN) against those supplied by the requested 
transaction. Again, if the parameters of the requested transaction do not conform 
of those specified in the pre-authorization table, the transaction is denied. 

When query task 414 determines that the parameters of the requested 
transaction conform to all other parameters specified in the pre-authorization table, 
an approved transaction task 416 authorizes the transaction in the affirmative. 
Although the above flow diagram has been specified in terms of task ordering, 
nothing precludes the evaluation of parameters or conditions in varying orders. For 
example, a merchant identifier specified in the pre-authorization table may be 
compared primary to the evaluation of the transaction amount without affecting the 
spirit of the invention. 

Figure 5 is a depiction of a billing account report associating a transaction 
identifier with a transaction yet to be billed, in accordance with an embodiment of 
the present invention. As discussed above, a transaction identifier 510 may be 
associated to a pre-authorized transaction generated by an account manager. 
Traditional billing statements presented to an account manager contain generic 
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information such as an account number, a transaction amount and information 
identifying a merchant. Historically, an account manager was then left to search 
back through claims, work orders or purchase orders to align a transaction amount 
and merchant identifier contained within the billing statement to an earlier 
authorization. 

In the present invention, a billing account 502 is comprised of an account 
number 504, merchant information 506, a transaction amount 508 and a transaction 
identifier 510. Transaction identifier 510, by containing descriptive information 
unique to the transaction, enables ah account manager to quickly identify a 
corresponding authorization document for account reconciliation. In the preferred 
embodiment of the present invention, transaction identifier 510 contains an alpha- 
numeric field which is defined by account manager 202 (Figure 202) and 
distributed to card issuer 214 using pre-authorization request 224, which in turn is 
forwarded to authorizing agent 212 and pre-authorization request 226, respectively. 
By allowing a transaction identifier to be associated with pre-authorization process, 
less sophisticated equipment such as transaction processing equipment resident at 
a merchant point of sale may remain relatively unsophisticated as such equipment 
does not process or pass through any additional parameters such as a transaction 
identifier but the account manager still gets a unique per transaction identification 
code. 

Figure 6 is a flow diagram illustrating account processing which employs 
pre-authorization of select transactions without requiring an account user to 
perform a payment presentment step, in accordance with an embodiment with the 
present invention. In the present embodiment, the established account phase 
proceeds according to that of the previous embodiment wherein an established 
account 616 and an established authorization step 618 establish an account number, 
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SIC limitations, transaction limitations and pre-authorization SICs requiring 
individual pre-authorization. 

An account user 604 requests goods or services of an account manager 602 
in a task 620. Account manager 602 negotiates a price quotation 622 from a 
merchant 606. Account manager 602 either upon resolution of a price quotation 
from a merchant 602 or, as discussed above, account manager 602 may obtain a 
quote amount value for placing within a pre-authorization request from other 
sources such as other standard pricing materials. 

In the present embodiment, account manager 602 provides merchant 606 as 
opposed to account user 604 with an account number in account disclosure step 624 
for utilization in a subsequent authorization request initiated by merchant 606. 
Following the disclosure of the account number to merchant 606, account 
manager 602 performs a pre-authorization request 626 in accordance with the 
description of the previous embodiment. A pre-authorization request 628 then 
flows from card issuer 614 to authorizing agent 612 for population of the pre- 
authorization table 318 (Figure 3). Such steps complete the pre-authorization 
phase of the account processing procedure. 

Upon the rendering of service or delivery of goods, merchant 606 
commences an authorization transaction process by issuing an authorization 
request 630 to authorizing agent 612 utilizing the account number delivered thereto 
by account manager 602 in account disclosure steps 624. Such an account number 
distribution technique is useful for applications such as insurance claim processing. 
For example, account user 604 assumes the role of an insured placing a claim 
against account manager 602, who further assumes the role of the insurer, or 
alternatively, a claims adjuster. Account manger 602 negotiates a repair price with 
a merchant 606 assuming the role, in the case of auto insurance, of a repair shop. 
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Upon completion of the negotiation process and the resolution of a claim 
amount, account manager 602 (i.e., claims adjuster) discloses an account number 
for use by merchant 606 (i.e., repair shop) for use in obtaining reimbursement for 
goods and services upon the completion of rendering such goods or services. 
Account manager 602 (i.e., claims adjuster) initiates pre-authorization request 626 
by including the divulged account number, and any other parameters deemed 
necessary (e.g., merchant identification number). Furthermore, to aid account 
manager 602 (i.e., claims adjuster) in reconciling their accounting system, account 
manager 602 includes a transaction identifier, which by way of example may be in 
the form of an insurance claim number uniquely identifying the requested claim by 
the insured. 

Upon the rendering of services or the delivery of goods, merchant 606 (i.e., 
repair shop) issues an authorization request 630 comprising the account number 
disclosed with the amount of the transaction and other identifiers flowing 
therewith. Authorizing agent 612 performs an authorization procedure and renders 
an authorization response 632 stating the status of either acceptance or denial of 
the requested transaction to merchant 606. Merchant 606, at a periodic interval, 
issues a settlement request 634 containing the account number, transaction amount 
and other identifying fields to authorizing agent 612 for account reconciliation. 
Authorizing agent 612 processes the settlement request in conjunction with card 
issuer 614 in a settlement request 636 including the account and transaction-related 
information such as account number, transaction amount, merchant 
number/name/address and the transaction identifier tieing the present billing line 
item to the originating claim number as delivered to account manger 602 in billing 
account step 640 as further received from settlement request step 636, and 
settlement response steps 638 and 639. 
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As briefly described above, the present invention provides a mechanism for 
utilizing existing account processing infrastructure such as existing point of sale 
terminals which are generally incapable of inputting additional information such 
as a transaction identifier into a transaction. In the present embodiment, 
associating a transaction identifier to a specific transaction is transparent to an 
account user, merchant, acquiring bank and bank card association. Furthermore, 
because of the services provided by the card issuer to the account manager, the 
account manager may establish, edit and delete pre-authorizations at will without 
exhaustive and expensive account-modifying parameters as historically required. 

Figure 7 is a simplified transaction diagram for use in wide-area networking 
environment in accordance with a preferred network embodiment of the present 
invention. The present embodiment finds application for use in an environment 
wherein an account user must divulge an account number in order to make a 
purchase using a transaction device such as a credit card or other similar device. 
In environments where the physical or personal presentment of such a transaction 
card or device is impracticable such as in a telephonic transaction or in a preferred 
embodiment such as in the use of a computer network such as the Internet network. 
Users or consumers have heretofore been reluctant to divulge their account number 
into an amorphous and unknown domain for fear of an unscrupulous merchant 
acquiring their account number and utilizing the account number for unauthorized 
transactions. An account user or consumer has heretofore been required to rely 
upon the integrity of a remote merchant in order to safeguard against such abuses. 
In the present embodiment, however, a user/consumer is issued an account number 
that when used will be denied unless a specific transaction has been individually 
pre-authorized by the user/consumer. Such a process is detailed in Figures 7 and 
8. In Figure 7, in a step 700 a consumer discovers through whatever process the 
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consumer chooses, a particular product of interest. The consumer may discover 
such a product either by shopping on the Internet or through other forms of 
shopping which include other forms of remote shopping such as catalog perusal as 
well as other imaginable forms of shopping. In prior remote shopping environment 
applications, a user would immediately thereupon divulge their account number. 
In the present network embodiment, the consumer in a step 702 transitions to a pre- 
authorization environment such as a pre-authorization web page on the Internet. 
In the network embodiment of the present invention, the user performs a login 
procedure or other security procedure for authenticating or otherwise identifying 
the accessing user/consumer as being a bona fide user/consumer. Such an 
authentication process may take the form of a login and password or PIN or other 
verification or authentication processes known by those of skill in the art. The 
user/consumer may alternatively present the account number to such an 
authorization page, or the authorization page may match the user/consumer's login 
and password data with a stored account number. During such a pre-authorization 
process, the pre-authorization values entered by the user/consumer are stored in a 
database 704 and may be comprised of an account number, a transaction valid 
duration (good through) date, a quote or value amount, a variance, and any other 
miscellaneous identification fields. Upon the termination of the pre-authorization 
step 702 and the storage in database 704, the pre-authorization information is 
forwarded to a database that is accessible by the transaction authorizing agent. It 
should be appreciated that the transaction authorizing agent may be one and the 
same as the authorization web page provider or any of the other transactional 
entities including the bank card association or card issuer. 

Following the pre-authorization process described above, the consumer 
returns in a step 706 to the web merchant's web page, in the instance of an Internet 
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environment, to proceed with the purchasing transaction. In the" step 706, the 
user/consumer offers to the web merchant an account number. In the present 
embodiment, the user/consumer operating with an account number that specifically 
requires the pre-authorization process performed immediately above derives a 
sense of security knowing that the act of divulging the account number to a 
merchant would only enable that specific merchant to successfully utilize the 
divulged account number in at most a single transaction and for a specific amount. 
Therefore, the consumer is protected from unscrupulous merchants that would 
heretofore misuse a divulged account number. 

Such a pre-authorization embodiment as described herein appears 
transparent to all merchants. Following the account number divulging act by the 
consumer to the merchant, the web merchant in a step 70S performs a traditional 
authorization request which in a step 710 passes through an acquiring bank, a bank 
card association *o an authorizing agent. The authorizing agent thereupon performs 
an authorization with the account number and any other associated information 
passed on from the merchant such as the transaction amount. As part of the 
authorizing act, in a step 712 the account number with its accompanying 
transaction amount is compared against the previously pre-authorized information 
which was in the preferred embodiment sent to the authorizing agent for storage as 
received at the authorization web page. Once a comparison has been made of the 
pre-authorized "amount" and the transaction amount as received in the 
authorization process from the merchant, the authorizing agent will thereafter 
either approve or deny the transaction according to the pre-authorization 
parameters. The authorizing agent in a step 714 also subjects the transaction to the 
traditional standard authorization checks such as credit limits and any variations 
including an account in good standing. Following the pre-authorization checks in 
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step 712 and the standard authorization checks in step 714, the authorizing agent 
may thereupon either decline the transaction in a step 716 or approve the 
transaction in a step 718. 

If a transaction is approved, the pre-authorization process previously 
performed is either deleted from the system or deactivated, thereby preventing any 
unscrupulous subsequent attempts to utilize the divulged account number. Any 
additional transactions desired to be performed by the user/consumer require the 
user/consumer to undergo the pre-authorization process described above in steps 
702 and 704. Since each of the pre-authorization requests is valid for only a single 
transaction, a particular user/consumer derives additional peace of mind in 
employing an otherwise vulnerable account number in performing remote 
commerce such as electronic commerce. 

Those skilled in the art appreciate that other applications of the above- 
described technology may also be employed in applications such as transactions 
engaged in by a user/consumer to other remote entities such as catalog merchants 
by using a computer interface pre-authorization approach or alternatively through 
a telephonic interface which enables a user to specify an account number and a 
quotation or potential transaction amount. 

Figure 8 is a flow diagram of the immediately above described pre- 
authorization process for use in a wide-area networking environment. 

It is appreciated that a potential user of the system would need to establish 
an account. In a step 816 a web account user or a consumer 804 interacts with a 
card issuer 814 to obtain an account number and other various limits such as 
transaction limits and even specific transaction type limits. Following the 
establishment of an account step 816 between a potential web account user and a 
card issuer, a step 818 establishes the authorization restrictions with the 
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authorizing agent 812. While not explicitly shown, the authorizing agent must also 
be aware of the corresponding account number as well as the transactional limits 
and other various limits placed upon a user's account transactions. In one 
implementation of the present embodiment, card issuer 814 may issue a unique 
series of account numbers which uniquely identify to authorizing agent 812 that 
particular transaction employing such a unique account number require the pre- 
authorization process before any transactions may be approved. 

Following the establishment of account stage, a user engages in traditional 
shopping or browsing of the preferred environment, one of which may take the 
form of electronic shopping on the Internet. In a step 820, the web account user 
804 discovers a web merchant page 806 bearing a preferred good or service to be 
acquired by web account user 804. In a step 822, web merchant page 806 discloses 
a price quotation or a quotation amount which may in its simplest form be a textual 
listing on the web merchant page of a sale amount. Once a web account user 804 
determines the desirability of a web merchant's good or service, the web account 
user 804 engages in a pre-authorization process with an authorization web page 815 
which is affiliated in some manner with a card issuer or other service provider 
which presents a front-end interactive environment to the web account user 804. 
As alluded to above, an alternate embodiment may employ a telephonic or other 
interactive front-end enabling a web account user the ability to pre-authorize a 
forthcoming transaction. 

In the login step 823, the user may interface with the authorization web 
page 815 in any of several traditional login procedures such as the offering of a 
login alpha numeric string followed by the input of a password and may 
alternatively require the user to enter an account number. In a step 824 the web 
account user 804 includes the specific parameters within which a forthcoming 
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transaction must comply. Such parameters may include the divulging of an account 
number, a transaction amount or quotation amount including a variance which may 
allow a user to approximate a percentile taxation rate. Alternative parametric 
information may also include a duration in which a transaction must be performed 
else the pre-authorization becomes stale and therefore invalid. The use of a 
transaction valid duration date also known as a "good through" date enables a user 
that anticipates an imminent transaction to specify a duration date or time which 
minimizes the exposure to any account number misuse. In a step 826 the pre- 
authorization request is forwarded from the authorization web page 815 to the 
authorizing agent 812 that will subsequently perform any authorization requests 
received from a merchant. 

Following the pre-authorization phase, the web account user 804 returns to 
the web merchant page 806 in a step 828 to consummate: the transaction by 
presenting the web account user's account number. Thereafter the web merchant 
performs an authorization request 830 with authorizing agent 812 in a traditional 
transaction fashion by submitting an account number and a transaction amount 
along with any other miscellaneous identifying parameters. Authorizing agent 812 
thereafter performs the authorization process described above in Figure 7 and 
returns in a step 832 an authorization response in the form of an acceptance or a 
denial of the account number for use in payment for the requested transaction. 

Account settlement and account reporting take a similar form as to the other 
embodiments described in previous figures in that in a step 834 the web merchant 
requests a settlement with the authorizing agent which thereafter transfers a 
settlement request in a step 836 to the card issuer which sends payment in steps 838 
and 839 to the web merchant's acquiring bank. The report accounting stage also 
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forwards in a step 840 a billing account from the card issuer to the web account 
user which contains traditional account statement information described above. 

Figure 9 depicts a block diagram of an authorization table including both 
standard and pre-authorization table as stored within an authorizing agent in 
accordance with a preferred network embodiment described herein. The 
authorizing agent described herein in the network embodiment stores an 
authorization table 900 containing a list of accounts which require pre- 
authorization as established during an account establishment stage. The 
authorizing agent upon receiving the established account authorization for a 
particular account number populates a corresponding standard authorization table 
910 with traditional information such as account limits 912, transaction limit 914, 
and a balance limit 916, A particular account such as account number 904 
requiring pre-authprization prior to authorizing a transaction also has associated 
therewith a pre-authorization table 918 which has the corresponding account 
number 920 and other pre-authorization fields described herein above. One such 
field is a quotation amount 922 which is the pre-authorized amount that a 
user/consumer input during the pre-authorization stage. Other values input by the 
user/consumer during the pre-authorization phase may include a variance amount 
and a transaction valid duration or "good through" date as well as any other 
miscellaneous I.D. information. Such information is thereafter referenced by the 
authorizing agent during an authorization transaction stage. 

A particular network embodiment has been described herein having 
applications to a consumer to business transaction. In such an environment, a user 
specifically pre-authorizes a forthcoming transaction thereby providing a narrow 
window in which a transaction must be consummated. By enabling a user to 
specifically pre-authorize a forthcoming transaction with the inclusion of specific 
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transaction parameters, provides an additional control against misuse of account 
numbers which must be divulged to engage in remote commerce where physical 
presentment of a physical instrument such as a credit or debit card is infeasible. 
It is contemplated that other remote environments may employ the process as 
described herein without departing from the spirit of the invention. Such 
additional environments and embodiments are contemplated within the scope. 

The present invention may be embodied in other specific forms without 
departing from its spirit or essential characteristics. The described embodiments 
are to be considered in all respects only as illustrative and not restrictive. The 
scope of the invention is, therefore, indicated by the appended claims rather than 
by the foregoing description. All changes which come within the meaning and 
range of equivalency of the claims are to be embraced within their scope. 

What is claimed and desired to be secured by United States Letters Patent 
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1 . In a network environment, an account authorization method wherein 
a portion of account transactions require individual pre-authorization, said method 
comprising the steps of: 

a) establishing an account between network user and an account 
issuer, said account having an imposed pre-authorization transaction 
designator for denoting said portion of account transactions that require 
said individual pre-authorization; 

b) said network user pre-authorizing said account upon a match 
of each of at least one specified transaction parameter of said imposed pre- 
authorization transaction designator to authorize a requested transaction; 
and 

c) authorizing said requested transaction when in conformity with 
each of said at least one specified transaction parameter. 

2. In a network environment, the account authorization method as 
recited in claim 1, wherein said establishing an account step comprises the step of 
designating a transaction valid duration period as said imposed pre-authorization 
transaction parameters. 
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3. In a network environment, the account authorization method as 
recited in claim 1, wherein said pre-authorizing step comprises the step of 
designating said at least one specified transaction parameter as a quotation amount 
describing a price boundary under which to authorize said requested transaction. 

4. In a network environment, the account authorization method as 
recited in claim 3, wherein said designating said at least one specified transaction 
parameter as a quotation amount step further comprises the step of designating a 
variance parameter from said quotation amount as one of said at least one specified 
transaction parameters. 
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5. In an account authorization system for facilitating the authorization 
of account transactions occurring in a network environment wherein a portion of 
said account transactions require individual pre-authorization, a method for 
authorizing said portion of said account transactions requiring individual pre- 
authorization comprising the steps of: 

a) receiving an authorization table of an account established 
between a network user and an account issuer, said authorization table 
capable of having a pre-authorization transaction designator to denote said 
portion of account transactions that require said individual pre- 
authorization; 

b) receiving in a pre-authorization table within said authorization 
table as a result of a pre-authorization process by said network user at least 
one specified transaction parameter for association with said 
pre-authorization transaction designator; and 

c) authorizing said requested transaction when parameters from 
a requested transaction authorization are in conformity with each of said at 
least one specified transaction parameter. 
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6. In an account authorization system for facilitating the authorization 
of account transactions occurring in a network environment wherein a portion of 
said account transactions require individual pre-authorization, the method for 
authorizing said portion of account transactions requiring individual 
pre-authorization as recited in claim 5, wherein said receiving in a pre- 
authorization table step further comprises the step of receiving a quotation amount 
as said at least one specified transaction parameter describing a price boundary 
under which to authorize said requested transaction. 

7. In an account authorization system for facilitating the authorization 
of account transactions occurring in a network environment wherein a portion of 
said account transactions require individual pre-authorization, the method for 
authorizing said portion of account transactions requiring individual 
pre-authorization as recited in claim 6, wherein said receiving a quotation amount 
as said at least one specified transaction parameter step further comprises the step 
of receiving a variance parameter designating an allowable deviation from said 
quotation amount as one of said at least one specified transaction parameters. 
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8. An account authorization system for facilitating the authorization of 
account transactions occurring in a network environment wherein said account 
transactions require individual pre-authorization, said system comprising: 

a) an account between a network user and an account issuer, said 
account having associated therewith an authorization table to designate said 
account transactions that require said individual pre-authorization; 

b) a pre-authorization table comprising at least one specified 
transaction parameter as required to authorize a requested transaction; and 

c) means for authorizing said requested transaction when in 
conformity with said at least one specified transaction parameter. 

9. The account authorization system as.recited in claim 8, wherein said 
at least one specified transaction parameter is a quotation amount describing a 
price to authorize said requested transaction. 

10. The account authorization system as recited in claim 9, wherein said 
at least one specified transaction parameter further comprises a variance parameter 
from said quotation amount. 

1 1 . The account authorization system as recited in claim 8, wherein said 
means for authorizing said requested transaction comprises an authorizing agent 
for receiving said at least one specified transaction parameter, comparing said at 
least one specified transaction parameter against at least one corresponding 
requested transactions parameter and approving said requested transaction upon 
conformity therewith. 
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12. In an account authorization system for facilitating the authorization 
of account transactions occurring in a network environment wherein a portion of 
said account transactions require individual pre-authorization, a computer-readable 
medium having computer-executable instructions for authorizing said portion of 
account transactions requiring individual pre-authorization for performing the steps 
of: 

a) receiving an authorization table of an account established 
between a network user and an account issuer, said authorization table 
capable of having a pre-authorization transaction designator to denote said 
portion of account transactions that require said individual pre- 
authorization; 

b) receiving in a pre-authorization table within said authorization 
table as a result of a pre-authorization process by said network user at least 
one specified transaction parameter for association with said 
pre-authorization transaction designator; and 

c) authorizing said requested transaction when parameters from 
a requested transaction authorization are in conformity with each of said at 
least one specified transaction parameter. 
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1 3 . The computer-readable medium of claim 1 2 having further computer- 
readable instructions wherein said receiving in a pre-authorization table step 
further comprises the step of receiving a quotation amount as said at least one 
specified transaction parameter describing a price boundary under which to 
authorize said requested transaction. 

14. The computer-readable medium of claim 13 having further computer- 
readable instructions wherein said receiving a quotation amount as said at least one 
specified transaction parameter step further comprises the step of receiving a 
variance parameter designating an allowable deviation from said quotation amount 
as one of said at least one specified transaction parameters. 
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